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V  ABSTRACT 

WireLisp  is  a  language  that  incorporate"  both  procedural  and 
graphical  constructs  for  describing  the  structure  of  complex  cir¬ 
cuits.  This  combination  provides  both  the  clarity  of  a  graphical 
representation  and  the  expressiveness  of  a  procedural  descrip¬ 
tion.  This  paper  describes  how  this  is  done  in  a  conceptually 
simple  way  by  representing  procedural  information  graphically. 
WireLisp  is  built  on  Lisp  which  allows  the  designer  to  extend  the 
language  with  arbitrary  functions.  WireLisp  can  be  used  to  gen¬ 
erate  a  variety  of  different  target  output  descriptions,  and  allows 
the  incorporation  of  other  kinds  of  descriptions  such  as  behav¬ 
ioral  and  physical  descriptions.  WireLisp  is  implemented  in  T 
Lisp  and  has  been  used  to  describe  a  complex  (130,000  transis¬ 
tor)  VLSI  chip  design.  /  . 

'  '  '  rx  )  / _ 

Introduction  ( 

WireLisp  is  a  language  for  describing  the  structure  of  a  digital 
system.  Structure  refers  to  the  relationship  between  the  elements 
of  a  system  and  is  easiest  to  represent  and  understand  graphi¬ 
cally.  The  common  representation  of  circuits  is  thus  a  schematic 
representation  corresponding  directly  to  the  structure  of  the  cir¬ 
cuit.  The  concept  of  hierarchy  is  very  useful  in  describing  circuits 
and  can  be  incorporated  directly  into  schematic  descriptions  by 
allowing  subcircuits  comprising  related  modules  to  be  combined 
into  a  single  abstract  component.  This  abstraction  mechanism  re¬ 
duces  the  amount  of  information  required  to  understand  a  circuit 
description  at  any  one  level  by  hiding  information  within  abstract 
components.  Abstraction  extends  the  designer’s  grasp  by  remov¬ 
ing  unnecessary  detail  and  reduces  the  interaction  between  parts 
of  a  system  by  isolating  that  detail.  Combining  hierarchy  with 
graphical  constructs  provides  a  very  intuitive  and  structured  way 
to  describe  circuits  and  most  modern  schematic  drawing  systems 
incorporate  hierarchy. 

Although  graph.cal  descriptions  are  clear,  they  are  not  very 
expressive.  That  is,  there  sire  many  conceptually  simple  circuits 
for  which  graphical  descriptions  are  very  inefficient.  For  example, 
describing  a  32-bit  register  as  a  collection  of  32  flip-flops  requires 
a  large,  repetitive  schematic.  The  procedural  concept  of  itera¬ 
tion  is  a  much  more  expressive  way  to  describe  this  circuit.  The 
graphical  description  of  a  large  decoder  is  also  unwieldy  as  the 
circuitry  for  each  output  is  slightly  different  and  cannot  be  sim¬ 
ply  replicated  within  the  drawing.  However,  this  circuitry  can  be 
succinctly  described  using  iteration,  conditionals  and  the  ability 
to  perform  computation  on  the  iteration  variable.  Graphical  de¬ 
scriptions  are  also  “brittle” ;  simple  changes  in  the  parameters  of  a 
system  can  require  very  time-consuming  changes  to  the  schemat- 

1  This  research  was  supported  by  the  Defease  Advanced  Research  Projects 
Agency,  DARPA  Contract  #N00014-88-K-043J,  by  NSF  Grant  #CCR- 
8437589,  and  IBM  Contract  #87-453490. 


ics.  By  contrast,  procedural  descriptions  can  be  written  in  terms 
of  system  parameters  to  adjust  to  new  values  without  modifica¬ 
tion.  Thus  procedurally  based  descriptions  can  efficiently  specify 
the  large,  regular  circuits  from  which  large  digital  systems  are 
constructed. 

U  nfortunately,  procedural  descriptions,  while  expressive,  are 
obscure.  That  is,  the  structure  of  a  circuit  is  not  immediately 
obvious  from  a  procedural  description.  Both  writing  and  un¬ 
derstanding  procedural  descriptions  can  be  very  difficult.  The 
approach  of  some  schematic  systems  is  to  allow  limited  proce¬ 
dural  constructs  in  circuit  drawings.  For  example,  arrays  might 
be  used  as  a  limited  form  of  iteration  to  generate  several  copies 
of  a  device  or  a  signal.  Parameters  may  be  allowed  in  this  con¬ 
text  to  allow  differently  sized  components.  While  this  increases 
the  expressiveness  of  schematic  drawings,  it  is  only  in  a  limited 
form  that  corresponds  to  syntactic  textual  substitution.  Without 
variables,  conditionals  and  general  iteration  many  circuits  can  be 
described  only  inefficiently. 

The  goal  of  WireLisp  is  to  incorporate  full  procedural  power 
into  graphical  descriptions.  Since  it  is  difficult  to  predict  all  the 
constructs  a  user  will  need,  WireLisp  imposes  no  restrictions  and 
includes  the  full  range  available  in  Lisp.  Indeed,  the  user  is  free 
to  define  and  use  new  functions.  Whether  a  circuit  is  described 
graphically  or  procedurally  is  a  decision  left  to  the  designer  who 
can  choose  the  appropriate  approach  based  on  the  type  of  cir¬ 
cuit  being  described.  Moreover,  procedures  and  graphics  can  be 
freely  intermixed.  That  is.  Lisp  expressions  can  be  embedded  in 
graphic  descriptions  and  graphic  descriptions  embedded  in  Lisp 
expressions.  This  allows  descriptions  that  are  highly  expressive, 
yet  easily  specified  and  understood. 

The  underlying  model  of  WireLisp  uses  procedures  to  de¬ 
scribe  how  devices  are  constructed.  A  device  procedure  is  invoked 
to  create  an  instance  of  the  device,  which  may  vary  according  to 
the  parameters  passed  to  the  procedure.  An  example  of  the  def¬ 
inition  of  a  device  called  treecomp  is  given  in  Figure  1.  This 
device  compares  two  N-bit  numbers  using  a  recursive  divide  and 
conquer  approach.  While  this  description  relies  heavily  on  proce¬ 
dural  constructs,  the  resulting  circuit  structure  is  quite  obvious 
from  the  circuit  drawing. 

Device  procedures  are  typically  specified  using  a  drawing  ed¬ 
itor,  but  they  can  also  be  produced  by  other  CAD  tools  such 
as  logic  synthesis  programs.  Thus  one  device  may  be  described 
graphically  while  another  described  using  a  behavioral  descrip¬ 
tion  which  is  converted  into  a  WireLisp  procedure  by  a  synthesis 
tool  such  as  a  PLA  or  multi-level  logic  generator.  The  output  pro¬ 
duced  by  a  WireLisp  program  is  also  flexible  since  it  is  produced 
by  the  device  procedures  themselves.  Although  device  libraries 
can  be  provided  for  common  devices  and  technologies,  the  user 
can  easily  produce  whatever  output  is  desired.  WireLisp  provides 
a  structural  framework  for  specifying  a  system  as  a  collection  of 
components  described  in  different  ways. 
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Related  Work 

Programming  language*  have  been  used  before  to  describe  cir¬ 
cuits,  notably  the  use  of  Lisp  in  netliat  [12]  and  DPL[4|.  WireLisp 
is  similar  to  netliat  in  its  use  of  procedure  hierarchy  and  its  def¬ 
inition  of  device  connection*  via  parameters.  However,  netliat 
is  purely  procedural  and  is  unwieldy  for  representing  complex 
systems.  Moreover,  netliat  has  only  a  very  primitive  notion  of 
signal  structure  that  prevents  information  hiding. 

Both  graphically  and  procedurally  based  VLSI  layout  systems 
have  been  described,  but  little  has  been  done  to  incorporate  both 
types  of  description  in  the  same  specification.  Some  systems  such 
as  Mocha  ChipflO]  and  WIN[1]  use  both  types  of  description  in 
the  specification  of  chip  layout,  but  they  cannot  be  intermixed 
at  a  fine-grained  level. 

Xerox  PARC  has  recently  produced  a  circuit  specification  sys¬ 
tem  that  incorporate*  both  graphics  and  programs[2,  3]  that  is 
similar  in  philosophy  to  WireLisp.  The  mechanism  in  WireLisp  is 
conceptually  simpler  which  allows  extensions  to  be  defined  more 
easily.  WireLisp  also  intertwines  the  graphical  and  procedural 
constructs  more  closely  which  yields  specifications  that  are  more 
expressive  and  self-apparent. 

The  WireLisp  Model 

In  the  model  that  WireLisp  uses,  each  device  in  a  circuit  descrip¬ 
tion  is  a  procedure  that  describes  how  it  is  constructed.  When 
a  module  is  used,  this  procedure  is  executed  to  generate  an  in¬ 
stance  of  the  module.  A  device  procedure  may  be  parameterized 
and  therefore  define  an  entire  family  of  devices. 


Devices  are  either  composite  or  leaf  devices.  Composite  de¬ 
vices  are  comprised  of  other  devices  while  leaf  devices  are  prim¬ 
itive  devices  without  components.  An  instance  of  a  composite 
device  is  constructed  by  first  invoking  the  device  procedures  of 
its  components  and  then  connecting  the  resulting  instances  to¬ 
gether.  Leaf  devices  have  no  component  device  procedures  to 
invoke,  but  instead  perform  actions  such  as  writing  the  appro¬ 
priate  description  of  the  device  to  an  output  file. 

Devices  are  connected  together  via  named  signals  which  cor¬ 
respond  to  wires  in  the  actual  circuit.  These  signals  are  connected 
to  devices  via  signal  parameters  which  correspond  to  the  termi¬ 
nals  of  the  physical  device.  When  a  device  procedure  is  called, 
each  signal  parameter  is  bound  to  the  signal  in  the  environment 
of  the  device  to  which  the  terminal  is  connected.  Thus  devices 
are  interconnected  by  connecting  them  to  common  signals. 

Device*  may  also  have  general  parameter*  which  describe 
which  instance  of  a  family  of  device*  i*  to  be  constructed.  Op¬ 
tional  parameter*  with  default  value*  are  also  provided  to  reduce 
the  amount  of  information  required  in  the  circuit  description. 
In  Figure  1,  >  is  a  general  parameter  indicating  the  size  of  the 
numben  being  compared. 

A  complete  hierarchical  WireLisp  description  becomes  a  pro¬ 
gram  with  nested  procedure  calls  corresponding  to  the  circuit 
hierarchy.  This  program  is  executed  to  produce  an  output  de¬ 
scription  which  depends  on  the  side  effects  of  the  procedure* 
during  program  execution.  For  example,  if  each  leaf  device  pro¬ 
cedure  writes  a  description  of  itself  to  an  output  file,  the  result 
will  be  a  flat  netlist  of  the  circuit.  On  the  other  hand,  the  pro- 
cedures  might  construct  an  in-core*  dati  structure  corresponding 
to  the  circuit,  or  make  entries  into  a  design  database.  The  result 
of  execution  is  thus  defined  by  the  user,  although  libraries  can 
be  provided  for  primitive  devices  in  common  target  technologies 
and  output  description  formats. 

Drawing  Device  Procedures 

Although  in  principle  the  designer  can  write  device  procedures 
directly,  the  intent  of  WireLisp  is  for  these  procedures  to  be  de¬ 
scribed  in  circuit  drawings  similar  to  schematics.  Typically,  most 
of  a  circuit  can  be  described  graphically,  with  conditionals  and 
iteration  used  as  required.  However,  even  procedural  constructs 
can  often  be  represented  graphically  as  shown  in  Figure  2.  Here 
the  if  form  is  represented  by  a  pseudo-device  which  acts  as  a 
compile-time  multiplexor  conditioned  by  the  variable  i:  The  first 
section  of  the  shift  register  is  connected  to  an  input  SI  instead 
of  the  output  of  the  previous  section. 


Figure  2:  A  graphical  form  of  the  Lisp  if  conditional. 


Each  device  definition  is  given  by  a  single  drawing  as  in  Fig¬ 
ure  1.  The  symbol  for  the  device  being  defined  is  placed  at  the 
top  of  the  page  and  corresponds  to  the  procedure  head.  The  in¬ 
terconnected  component  devices  are  placed  below  it  and  form  the 
body  of  the  procedure.  The  device  symbol  contains  named  con¬ 
nection  points  for  the  input/output  signals  of  the  device:  These 


are  the  signal  parameters  of  the  device.  Pins  are  used  to  mark  the 
connection  points  in  the  device  symbol,  and  the  device  definition 
provides  the  parameter  name  for  each  pin.  General  parameters, 
both  mandatory  and  optional,  are  simply  listed  next  to  the  device 
symbol. 

The  device  symbols  appearing  in  the  procedure  body  each 
corresponds  to  a  procedure  call.  The  names  of  the  wires  con¬ 
necting  these  symbols  via  connection  points  are  passed  as  the 
corresponding  actual  parameters  to  these  procedure  calls.  Device 
instances  may  specify  optional  parameters  that  do  not  appear  in 
the  device  definition,  in  which  case  they  are  ignored.  This  allows 
the  designer  to  attach  arbitrary  information  to  a  device  instance 
which  may  or  may  not  be  used  in  the  current  context.  For  exam¬ 
ple,  the  designer  can  include  layout  information  which  is  ignored 
by  a  definition  that  generates  a  netlist. 

Signal  wires  are  represented  as  simple  lines  in  the  drawing 
and  are  named  by  closely  placed  text.  The  signal  wires  appear¬ 
ing  in  the  procedure  body  must  either  be  a  formal  parameter,  i.e. 
an  input  or  output  signal,  or  be  declared  locally.  Defining  sig¬ 
nals  locally  allows  irrelevant  information  to  be  hidden  from  the 
surrounding  context.  Unnamed  wires  are  automatically  declared 
as  a  local  signals  and  assigned  uniquely  derived  names.  Different 
wires  with  the  same  name  are  considered  to  be  the  same  wire, 
and  naming  a  wire  more  than  once  creates  aliases  for  that  signal. 

Lisp  expressions  may  be  used  anywhere  in  a  drawing  and  are 
included  in  the  device  procedure  as  they  appear  in  the  drawing. 
The  most  commonly  used  Lisp  expressions  are  conditionals,  loops 
and  arithmetic  operations;  however,  any  Lisp  function  can  be 
used,  including  those  defined  by  the  user.  General  Lisp  functions 
can  appear  either  as  text  or  as  graphics  symbols  that  operate  over 
variables  and  signal  values.  Conversely,  circuit  drawings  may  be 
used  within  Lisp  expressions.  This  is  done  by  enclosing  the  circuit 
drawing  with  a  named  rectangle  and  referencing  this  name  in  a 
Lisp  expression.  Figure  1  contains  an  example  of  this:  The  if 
conditional  is  used  to  generate  one  of  two  circuits  depending  on 
the  size  of  the  input  values. 

Branch  points  can  occur  in  the  hierarchy  if  there  are  alter¬ 
native  definitions  of  a  device.  Design  alternatives  are  easily  im¬ 
plemented  in  WireLisp  by  using  a  conditional  statement  in  the 
device  definition.  For  example,  a  global  style  variable  could  be 
used  to  choose  among  a  number  of  different  types  of  output.  For 
simulation,  a  composite  device  may  be  implemented  as  a  func¬ 
tional  model  while  for  a  netlist,  its  details  would  be  completely 
generated. 

The  result  of  executing  a  WireLisp  program  can  be  defined  by 
the  user.  However,  the  user  will  typically  use  library  procedures 
for  a  particular  technology  and  a  standard  output  representation 
of  the  circuit.  The  most  common  use  of  WireLisp  produces  a  flat 
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representation  of  the  circuit  containing  only  primitive  devices 
connected  as  specified  in  the  WireLisp  program.  For  example, 
at  the  University  of  Washington  we  use  WireLisp  both  to  design 
CMOS  circuits  in  standard  SIM  or  COSMOS  format,  and  to 
perform  board-level  design.  However,  a  WireLisp  program  might 
just  as  well  build  an  in-core  representation  of  the  circuit  or  make 
entries  directly  into  a  design  database  like  Berkeley  OCT[S).  The 
flexibility  of  a  procedurally  based  descriptton  allows  the  general 
WireLisp  framework  to  be  used  for  a  wide  variety  of  applications 
with  only  a  small  amount  of  additional  work. 

Signals 

Simple  signals  in  WireLisp  correspond  to  wires  in  a  circuit  com¬ 
municating  values  between  devices.  At  higher  levels  of  abstrac¬ 
tion,  it  is  convenient  to  group  related  signals  together  and  refer  to 
them  collectively  as  a  unit.  Examples  include  busses,  control  sig¬ 
nals  and  dual-rail  values.  WireLisp  allows  signals  to  be  grouped 
together  into  complex  signals  called  cables.  A  cable  comprises  an 
ordered  set  of  signals  which  can  be  referenced  collectively  by  the 
name  of  the  cable,  or  individually  via  an  access  mechanism.  Ca¬ 
bles  are  created  via  a  local  declaration  which  declares  the  cable 
and  component  names.  Alternatively,  cables  can  be  created  dy¬ 
namically  handling  together  a  set  of  already  declared  signals 
using  the  «  ole  operator.  Cables  are  allowed  to  have  hierarchi¬ 
cal  structure  so  that  components  may  be  either  simple  signals  or 
cables. 

WireLisp  provides  two  different  ways  to  access  the  compo¬ 
nents  of  structured  signals:  records  and  busses,  corresponding 
to  records  and  arrays  in  conventional  languages.  Records  use 
named  selectors  to  access  elements  in  a  cable  while  busses  are  in¬ 
dexed.  WireLisp  separates  the  physical  structure  of  a  cable  from 
the  access  mechanism  used  to  access  its  components.  Thus  a 
structured  signal  may  be  referenced  in  different  ways  in  different 
devices.  For  example,  one  device  may  number  the  components 
of  a  bus  from  0  to  15  while  another  numbers  them  1  to  18. 

Cables  may  be  defined  either  textually  or  graphically  as  shown 
in  Figure  3.  Cables  are  accessed  in  a  straightforward  way  so  that 
any  component  in  the  structure  tree  can  be  referenced.  For  ex¬ 
ample,  sysBua- control  refers  to  the  three  signals  R/W,  STROBE, 
and  ACK  and  sysBus  ■  ADDRESS  [23]  refers  to  the  high-order  ad¬ 
dress  bit. 

When  a  cable  is  passed  as  a  parameter  to  a  device,  an  access 
structure  must  be  defined  in  order  to  access  its  components.  De¬ 
vices  only  need  to  declare  access  to  components  used  within  the 
device,  leaving  the  rest  hidden.  WireLisp  dynamically  checks  to 
make  sure  that  the  structure  used  to  access  a  cable  matches  the 
actual  physical  structure  of  that  cable.  In  some  cases  a  high-level 
device  may  connect  two  subdevices  together  with  a  cable  without 
knowing  how  large  the  cable  is.  In  this  case,  the  definition  of  the 
size  of  the  cable  can  be  delayed  until  a  subdevice  is  called  and 
explicitly  defines  it.  This  delayed  binding  provides  a  convenient 
way  to  specify  generic  modules. 

Cable  declarations  and  expressions  often  contain  long  lists  of 
similar  names.  WireLisp  provides  a  simple  mechanism,  called 
the  iterator,  for  describing  such  lists  of  names  succinctly.  Itera¬ 
tors  are  merely  syntactic  shorthand  used  to  reduce  the  amount  of 
repetitive  information  in  a  drawing.  An  iterator  occurring  in  a 
name  causes  that  name  to  be  expanded  into  a  list  of  names. 
An  iterator  has  the  form  nl:n2,  where  nl  and  n2  are  maxi¬ 
mal  substrings  of  digits  appearing  in  the  string.  For  example. 
datal6:31H  contains  the  iterator  16:31  which  expands  to  the 
list  datalfiH  datal7K  datalSR  . . .  4ata31H. 


Figure  3:  Graphical  and  textual  declarations  of  structured  signals . 


Behavioral  Information  in  WireLisp 

While  much  of  a  digital  system  is  best  described  structurally, 
there  are  parts  of  complex  systems  which  have  ao  obvious  struc¬ 
ture  but  whose  input-output  behavior  is  easy  to  describe.  Con¬ 
trol  logic  is  an  example  of  a  module  whose  specification  is  better 
given  behaviorally,  for  example  as  a  finite  state  machine. 

Behavioral  modules  are  incorporated  into  WireLisp  descrip¬ 
tions  by  invoking  synthesis  tools  to  generate  an  implementation 
in  the  form  of  a  WireLisp  procedure.  By  having  the  behavioral 
part  of  the  system  integrated  with  the  structural  description,  the 
system  can  be  designed,  evaluated  and  implemented  as  a  whole. 
For  example,  as  an  architectural  description  is  being  evaluated 
using  simulation,  the  description  of  the  behavioral  modules  can 
remain  at  the  abstract  level  and  simulated  functionally.  As  the 
implementation  is  being  detailed,  the  behavioral  description  can 
be  mapped  into  a  gate  or  transistor  implementation. 

Including  behavioral  modules  in  a  WireLisp  description  is 
straightforward.  A  module  is  created  with  »he  appropriate  input- 
output  signals  and  an  implementation  that  refen  to  the  behav¬ 
ioral  description  external  to  WireLisp.  For  example,  the  behavior 
may  be  given  as  a  set  of  logic  equations,  a  finite  state  machine  de¬ 
scription  in  a  high-level  language,  or  a  state  diagram.  WireLisp 
depends  on  other  tools  to  translate  this  description  into  an  ap¬ 
propriate  WireLisp  procedure.  For  example,  a  PLA  description 
might  be  translated  into  a  functional  model  for  simulation  or  into 
a  WireLisp  description  of  a  PLA  circuit  implementation.  This 
mechanism  of  incorporating  externally  described  modules  allows 
WireLisp  to  take  advantage  of  the  wide  range  of  synthesis  tools 
available  with  very  little  additional  effort. 

WireLisp  Implementation 

There  are  a  range  of  possible  implementations  of  WireLisp  de¬ 
pending  on  how  closely  the  drawings  and  their  interpretations  are 
bound.  We  describe  here  the  current  implementation  of  WireLisp 
which  uses  a  generic  drawing  program  and  an  interpreter  written 
in  the  T  dialect  of  Lispfll]. 

WireLisp  drawings  are  made  using  xdp[7],  a  version  of  a 
generic  drawing  editor  developed  at  Carnegie-Mellon  University 
that  runs  on  Sun  and  MicroVax  workstations,  xdp  supports  a 
variety  of  graphic  objects  including  lines,  text,  circles,  arcs  and 
spline  curves,  xdp  provides  some  help  with  circuit  drawing  with 
respect  to  connecting  lines  used  as  wires,  but  otherwise  does  not 
understand  the  semantics  of  circuit  drawing.  An  analysis  pro¬ 
gram  which  does  understand  these  semantics  converts  WireLisp 
drawings  into  WireLisp  procedures.  The  designer,  however,  only 
interacts  with  the  circuit  specification  via  the  drawings. 

xdp  has  a  macro  concept  whereby  a  group  of  related  objects 
can  be  bound  into  a  single  named  object  called  a  symbol.  Sym¬ 
bols  in  WireLisp  drawings  correspond  to  devices,  and  connection 
points  within  devices  are  represented  by  xdp  pins  around  the  pe¬ 
riphery  of  the  device.  Making  a  device  definition  involves  defining 
a  symbol  for  the  device,  copying  in  the  symbols  of  the  component 
devices  from  the  drawings  in  which  they  are  defined,  and  then 
connecting  them  using  lines  attached  to  their  pins. 

xdp  allows  the  designer  to  move  about  conveniently  in  the 
hierarchy  of  a  design  by  allowing  devices  to  be  “subedited”.  This 
causes  the  current  drawing  to  be  suspended  and  replaced  by  the 
drawing  for  the  device  being  subedited.  Editing  of  the  suspended 
drawing  is  resumed  when  the  subedit  is  completed.  Subeditting 
is  allowed  to  any  depth. 

The  execution  of  WireLisp  procedures  resulting  from  the  anal¬ 
ysis  of  the  drawings  is  performed  by  an  interpreter  written  in  T 
Lisp.  This  is  done  by  entering  the  interpreter  and  specifying  the 


name  of  the  root  device  to  be  executed.  As  component  device 
procedures  are  called,  the  corresponding  drawing  programs  are 
automatically  reanalyzed  if  they  have  changed  and  the  device 
procedures  autoloaded.  This  automatic  dependency  analysis  al¬ 
lows  designs  to  be  quickly  modified  and  recompiled  without  any 
explicit  information  from  the  designer. 

The  current  implementation  executes  WireLisp  programs  at 
the  rate  of  about  200  devices/second  for  moderately  complex 
CMOS  circuits  on  a  Sun-3/260  with  SMB  of  memory.  This  means 
that  even  a  large  circuit  with  100,000  transistors  can  be  processed 
in  about  10  minutes. 

Future  plans  for  WireLisp  include  writing  functions  to  make 
it  easier  to  incorporate  behavioral  descriptions  and  investigating 
ways  to  incorporate  physical  design  information  for  VLSI  module 
generation.  This  latter  information  could  be  used  to  drive  a  chip 
assembler  directly  from  a  WireLisp  description. 
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